Tailoring Enterprise Systems Engineering Policy for Project Scale and Complexity 

6th International Conference on Systems & Concurrent Engineering for Space Applications 

- SECESA 2014 - 
08-10 October 2014 

Vaihingen Campus, University of Stuttgart 
Germany 

Principal Author Renee I. Cox (1) , L. Dale Thomas, Ph.D. (2) 

(1) National Aeronautics and Space Administration 

Marshall Space Flight Center 
Systems Engineering Office 
Huntsville, Alabama 35812 
United States of America 
Email: renee.cox@nasa.gov 

(2) National Aeronautics and Space Administration 

Marshall Space Flight Center 
Office of the Director 
Huntsville, Alabama 35812 
United States of America 
Em ail: dale, th om as@n asa.gov 


INTRODUCTION 

Space systems are characterized by varying degrees of scale and complexity. Accordingly, cost-effective 
implementation of systems engineering also varies depending on scale and complexity. Recognizing that systems 
engineering and integration happen everywhere and at all levels of a given system and that the life cycle is an integrated 
process necessary to mature a design, the National Aeronautic and Space Administration’s (NASA’s) Marshall Space 
Flight Center (MSFC) has developed a suite of customized implementation approaches based on project scale and 
complexity. While it may be argued that a top-level system engineering process is common to and indeed desirable 
across an enterprise for all space systems, implementation of that top-level process and the associated products 
developed as a result differ from system to system. The implementation approaches used for developing a scientific 
instrument necessarily differ from those used for a space station. 

At NASA, policy is captured in NASA Procedural Requirements (NPRs) and is used to communicate requirements and 
expectations to be implemented across the Agency. The scope of NPRs varies, covering legal policies and policies 
regarding property, procurement, financial management, etc. Program formulation and program management policies 
are captured in the 7000 and 8000 series of NPRs, respectively. NPRs describe expectations originating from NASA’s 
customers and stakeholders, the Office of Management and Budget (OMB), Congress, Office of Federal Procurement 
Policy, etc. The requirements also capture expectations from lessons learned throughout the history of NASA and space 
flight. The NPRs communicate requirements for programs and projects and also the responsibility of Centers to develop 
and maintain an infrastructure that supports the development of NASA’s strategic goals. It is through the NPRs and the 
Centers’ responses that the Agency has been able to delegate authority to each of the 10 Centers in many areas, 
particularly programmatic and technical authority. It is through this delegation of authority that MSFC has taken the 
initiative to develop tailored recommendations for policy based on program and project scale and complexity. 

INTEGRATION 

For the purposes of this paper, the system being engineered is the establishment of policy expectations for all MSFC 
programs and projects. The elements of this policy include programmatic, technical, and safety and mission assurance. 



The first objective was to integrate these elements into a single, ‘one-stop shop,’ so as to increase efficiencies in 
understanding that which is required. By doing so, it was also recognized that the Center would achieve better 
consistency in its systems engineering approach by reducing project-to-project variation in implementation for space 
systems of similar scale and complexity. Beginning with the expectations of stakeholders, MSFC flowed down the 
policy requirements and integrated them into Marshall Procedure Requirements (MPR) 7120.1, MSFC Engineering and 
Program/Project Management Requirements [1]. This document then served as the single starting point for all 
programs, projects, and activities as they began the challenge of planning the work required to properly execute each 
program or project. MPR 7120.1 points to more detailed requirements in peer-level supporting documentation for the 
17 systems engineering processes and software engineering requirements. See Fig. 1. 

Within MPR 7120.1, there are two primary programmatic governance options, one for space flight, NPR 7120.5, Space 
Flight Program/Project Management [2], and one for research and technology, NPR 7120.8, Research and Technology 
Program/Project Management [3]. The governance option dictates the programmatic rigor by which the work will be 
reviewed, as well as the life cycle expectations. Generally speaking, space flight programs and projects require more 
scrutiny because of the complexity of space flight and its inherent risk. 

Integrating the Agency expectations into the ‘one-stop shop,’ MPR 7120.1, proved an excellent starting point, but the 
integration required was not yet complete. The derived expectations from the Center, including technical requirements 
stemming from MSFC’s engineering heritage, needed to be integrated into the policy also. Having the complete 
flowdown of requirements integrated with the expectations of the Center provided a complete system of policy 
expectations for programs and projects. Requirements were to reflect ‘what,’ was to be accomplished whereas guidance 
and best practices were to reflect ‘how’ to implement the requirement. The purpose of keeping the tried-and-true 
implementation methods separate from the requirements was to enhance flexibility with designing implementation 
approaches, while still maintaining the knowledge gained from decades of designing, developing, testing, and flying 
space systems. 
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Fig. 1. MSFC Integrated Policy for Programs/Projects 





PORTFOLIO 


The next steps were to define the diversity of the portfolio of programs and projects at MSFC and to bring some order in 
which for policy to be tailored. MSFC is fortunate to have a vast portfolio. The Center has responsibilities ranging from 
launch vehicles, to spacecraft, to experiments, to testing piece parts for other stakeholders. The programs and projects 
also vary based on launch opportunities. The portfolio products fly on launch vehicles, balloons, sounding rockets, even 
an airplane. The diversity of work in which the Center is involved is extremely beneficial in terms of maintaining and 
enhancing the Center’s engineering and program/project management capabilities. However, this diversity does 
represent some challenges with respect to policy and flexibility. To address the challenges resulting from a diverse 
portfolio, MSFC defined a set of mission types. The definitions include the Agency-defined mission categories, 
categories that are primarily based on costs, with Agency-defined payload risk classifications, i.e., classes A, B, C, or D. 
Table 1 shows the outcome of this definition effort: eight MSFC mission types. Note that the table was designed to 
capture the priority in which mission type decisions are made. For example, the primary factor in determining mission 
type is Program/Project Life Cycle Cost; therefore, that factor is listed first. Life cycle costs will most likely lead to the 
appropriate levels for national significance, risk tolerance, project complexity, etc., as the user works through the 
definition. It is worth noting that life cycle costs take into account the schedule afforded the project, time, and the size 
of the team. These key factors directly relate to project scale and complexity. Every distinction to be considered for 
determining the implementation approach and addressing policy completely and distinctly was integrated into the 
MSFC-defmed mission types. 


Table 1. MSFC Mission Types 





Project and Activity Categorization/Mission Types 






Projects 



Activities 


Type 1 

Type 2 


Type 3 


Type 4 

Type 5 



2. a 

2.b 

3. a 

3.b 

3.c 



Cost Guidance 
(Estimated LCC) 

greater than SIB 

S1B-S250M 

S250M - S100M 

S100M - S50M 

S50M - S10M 

less than $10M 

typically 1 greater than SIM/yror 
greater than S10M LCC 

typically 1 less than $lM/yror 
less than $10M LCC 

Priority (Criticality to 
Agency Strategic Plan) 

Any 

Any 

High 

Medium or low priority 

Low priority 

Low to very low priority 

High to Agency or Center 

Medium or Low 

Other Factors 

Significant 
Radioative Material 


Decision Authority 

NASA Associate 
Administrator 

NASA Mission Directorate Associate 
Administrator 

NASA Mission Directorate Associate Administrator or Designee 

Center Director or Designee 

Directorate/Office Manager or 
Designee 

Governing PMC 

Agency 

Mission Directorate 

Mission Directorate 

CMC 

Monthly Program Reviews 
Within Directorate/Office 

National Significance 

Very high 

High 

Medium 

Medium 

Low 

Very Low 



Risk Tolerance 

Class A Risk: Very 
low (minimized) 

Class BRisk: Low 

Class C Risk: Medium 

Class D Risk: High 

Class D Risk: High 

Class D Risk: High 



Description of the Types 
ofMission 

Human Space Fhght 
or very large 
Science/Robotic 
Missions 

Non-Human Space 
Fhght or 
Science/Robotic 
Missions 

Small Science (Human 
or Non human) 

Smaller Science (Human 
or Non human) 

Science (Human or 
non human) 

Science (Human or non 
human) 

Efforts supporting 
program/projects managed 
outside of MSFC, that come under 
the purview of the CMC per the 
criteria defined in MPR 7120.4 

Efforts supporting 
program/project managed 
outside of MSFC, that do not 
come under the purview of the 
CMC per the criteria defined in 
MPR 7120.4 

Complexity 

Very high to high 

High to Medium 

Medium to Low 

Low 

Low 

Low to Very Low 



Mission Lifetime 
(Primary Baseline 
Mission) 

Long (>5 years) 

Medium (2-5 years) 

Short (<2 years) 

Short (<2 years) 

Short (<2 years) 

Short (<2 years) 



Launch Constraints 

Critical 

Medium 

Few to none 

Few to none 

Few to none 

None 



Achievement ofMission 
Success Criteria 

All practical 
measures are taken 
to achieve minimum 
risk to mission 
success. The 
highest assurance 
standards are used. 

Stringent assurance 
standards with only 
minor compromises in 
application to 
maintain a low risk to 
mission success. 

Medium or significant 
risk of not achieving 
mission success is 
permitted. Minimal 
assurance standards 
are permitted. 

Significant risk of not 
achieving mission 
success is permitted. 
Minimal assurance 
standards are permitted. 

Significant risk of 
not achieving 
mission success is 
permitted. Minimal 
assurance 
standards are 
permitted. 

Significant risk of not 
achieving mission 
success is permitted. 
Minimal assurance 
standards are permitted. 



Examples 

HST, Chandra, 
Cassini, JIMO, 
JWST, MPCV, SLS, 
ISS 

MER, MRO, 
Discovery payloads, 
ISS Facility Class 
payloads, Attached 
ISS payloads 

ESSP, Explorer 
payloads, MIDES, 
ISS complex sub rack 
payloads, PA-1, 
ARES 1-X, MEDLI, 
CLARREO, SAGE III, 
Calipso, ISERV 

SPARTAN, GAS Can, 
technology 
demonstrators, simple 
ISS, express middeck and 
sub rack payloads, 
SMEX, MISSE-X, EV-2 

IRVE-2, IRVE-3, 
HiFIRE, HyBoLT, 
ALHAT 
Earth Venture I, 
FASTSAT 

DAWNAir, InFlame, 
Research, technology 
demonstrations , 
HEROES, SWORDS 
Payloads , Nanosails 

ADDITIVE Manufacturing in 
Space 

MSFC activities in support of a 
request frompro gram/project 
outside of MSFC, for MSFC 
supporting activities. Subject 
to requesting organization's 
requirements . 


LIFE CYCLES 


There are seven life cycle types defined at NASA. (1) Uncoupled/loosely coupled programs are programs implemented 
under a broad theme, whose projects are independent of each other and do not have a common interface. The primary 
function of this life cycle is to oversee and manage the projects manifested under them. The Technology Demonstration 
Mission (TDM) is an example of an Uncoupled Program. (2) Another life cycle type is a Tightly Coupled Program. 
Tightly Coupled Programs are programs whose projects execute portions of the mission. Under Tightly Coupled 
Programs, no single project is capable of implementing a complete mission. The International Space Station (ISS) is an 
example of a Tightly Coupled Program. (3) Single Project Programs are programs that have combined program and 
project management approaches. These programs tend to have long development and/or operational lifetimes and 
represent a large investment of Agency resources. They develop elements and also integrate those elements into a 
system. The Space Launch System (SLS) is an example of a Single Program Project (SPP). (4) A project is a specific 
investment identified in a Program Plan. Projects have a management structure, defined requirements, life cycle cost, 
and possible interfaces to other projects, agencies, and international partners. The High Energy Replicated Optics to 
Explore the Sun (HEROS) project, flown on a balloon, is an example. (5) The Research & Technology (R&T) Program 
is an Agency program strictly comprised of R&T projects. The R&T Program life cycle is another program 
management function, similar to uncoupled and loosely coupled programs, whose focus is overseeing and managing the 
R&T projects underneath them. (6) Technology Development (TD) Projects utilize a life cycle for R&T projects whose 
Technology Readiness Level (TRL) is greater than five. For TRLs less than five, the (7) R&T Portfolio life cycle is 
used. An example of an R&T project is the Green Propellant Infusion Mission (GPIM). 

Within each of the seven life cycles there are different programmatic requirements and different design review 
expectations. Technical requirement expectations are virtually the same, in that an assessment of the traditional 17 
systems engineering processes is required of all life cycles. Safety and Mission Assurance requirement expectations will 
vary based on risk posture, flight carrier, and whether the program or project is manned or unmanned. 

CUSTOMIZATION TOOL 

In an effort to successfully conduct a variety of missions in a more timely and efficient manner, MSFC initiated an 
activity to review policy and develop a systematic method of providing a tailored starting point for programs and 
projects based on project scale and complexity. The activity also promoted better consistency by reducing the project- 
to-project variation of systems engineering implementation for space systems of similar scale and complexity. In 
essence, the challenge of marrying the integrated policy to the diverse portfolio of programs and projects to the life 
cycle was undertaken. Affordability, efficiency, and completeness led the MSFC team to develop a customization 
software application (tool) to answer the challenge. Given a project classification, customized implementation 
approaches of the MSFC systems engineering policy were developed on the basis of recognized best practices and 
lessons learned from similar systems. For each life cycle, the tool provides a comprehensive list of products and design 
reviews expected for each decision point, along with a recommendation for tailoring based on mission type. 

Walking through the logic flow of the tool, as shown in Fig. 2, the user 

1 . Determines the type of governance to be used: space flight or research and technology 

2. Determines the mission type: 1, 2a, 2b, 3a, 3b, 3c, 4, or 5, as defined in Table 1 above 

3. Determines the program/project life cycle 

Once all the selections have been made, the user is given a tailored set of minimum design reviews and their associated 
products for consideration, which is a subset of the complete integrated set of all expectations, i.e., worst case. Fig. 2 
below captures all the options and gives the reader a complete picture of the integration within the tool. Note that for 
each of the reviews in the logic flow, the color of the text in the box is significant: black = Agency required review, 
green = MSFC added required review, blue = MSFC added optional review. Also note that although the option to select 
‘Ground,’ ‘Manned,’ ‘Unmanned’ only appears on the right under R&T Governance, it is understood that space flight 
will be either ‘Manned’ or ‘Unmanned.’ The primary difference between ‘Manned’ and ‘Unmanned’ on either side of 
the logic flow will be in the Safety and Mission Assurance requirement set. The reason for showing these options under 
R&T is to make allowance for projects flown aboard airplanes. The result of the integrated customized implementation 
approaches supports the Center initiative of more informed risk-based decision-making and affordability. It is important 
to emphasize that the output of the tool represents a recommended starting point for addressing policy. The tool output 



is not intended to be interpreted as a required starting point. The engineer is always expected to do what is appropriate 
for the circumstance. 
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Fig. 2. Tailoring Logic Flow 
(See page 7 for Acronym list) 
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COMPARE AND CONTRAST 


Stepping through the tool, we will compare and contrast the SLS Program, an NPR 7120.5- governed Program, to the 
GPIM, an NPR 7120.8-governed mission. SLS has life cycle costs greater than $1 Billion, is of very high national 
significance, and has a very low-risk posture. It is a Type 1 on the MSFC Mission Types table. GPIM is between a $50 
Million - $10 Million project of low national significance and has a high-risk posture. It is considered a Type 3b on the 
MSFC Mission Types table. As previously mentioned, SLS follows the SPP life cycle, while the GPIM, with a TRL 
level greater than five as of this date, follows the TD life cycle. The output of the tool shows the difference in the 
minimum set of design reviews required for each. See Table 2. The whole suite of reviews is expected of SLS, a very 
complex program, while a smaller number of reviews is expected for the GPIM, a low complexity project. Because SLS 
is an SPP, its reviews will address the program integration aspect of the project as well. Remember, SPPs are a 
combination of program and project functions. It could be considered a combination of the reviews shown under 
Tightly Coupled program and project. Because an SPP would combine these two perspectives into one review, the 
individual reviews are not listed separately below; however, addressing two perspectives does significantly change the 
scope of the review. Because the scope of the review is different, the product expectations will also be vastly different. 


Table 2. Design Review Difference 











SLS Reviews 

GPIM Reviews 

MCR 


SRR 

SRR 

SDR 


PDR 

PDR 

CDR 

CDR 

PRR 


SIR 

SIR 

DCR 

DCR 

ORR 


FRR 

FRR 

PLARR 


CERR 


PFAR 


DR 


DRR 



The product expectation differences are also captured in the tool and can be viewed as one delves deeper. By selecting 
the review of interest, the tool provides a listing of product expectations for that phase of the life cycle. SLS, because it 
is an SPP, would have the additional technical function of program integration, for which GPIM would not be 
responsible. The additional function would require the SLS product set to address the added scope. For example, SLS 
will produce Integrated Ascent Mission Timelines, where as the flight carrier for GPIM would produce this type product 
with inputs from GPIM. 

From a programmatic perspective, both SLS and GPIM involve the same functions: Safety and Mission Assurance, risk 
management, basis of estimate, education outreach, lessons learned, etc. However, project complexity drives stand- 
alone products for each of these for SLS (28 stand -alone plans), while they can all be captured in the single project plan 
for GPIM. 

Technically both projects would be required to do a Systems Engineering Management Plan, in which the traditional 17 
systems engineering processes are assessed and that assessment captured. The magnitude of performing the work is 
different. As an example, both SLS and GPIM are required to do requirements management, but complexity differences 
between the two projects mean that the amount of work necessary to perform requirements management and flowdown 
for SLS differs greatly in magnitude from that required of GPIM. 

SUMMARY 

Taking a systems engineering and integration approach to the system of program and project management policy, 
MSFC has integrated myriad standards and expectations from the Agency with requirements of the Center and 
integrated those requirements with best practices and integrated mission types with NASA life cycles. This integration 
is performed one time for all the Center’s programs and projects to use, allowing the program/project teams to apply 
their resources on developing an implementation approach that best matches their project scale and complexity. When 
thinking of it in terms of the Systems Engineering Vee [4], the Center, utilizing its heritage, has tackled the left hand 
side of the Vee, allowing the program and project teams to focus attention on the right hand side of the Vee, as they 
develop their implementation plans. Utilizing the tool allows a common basis for all MSFC programs and projects to 
make informed risk assessments, both at the engineering level and the management level. It also serves as a feedback 
mechanism for the implementers, based on lessons learned that could be applied to enhance the system for future 
generations. To date, the customization tool has been exercised on SLS, HEROES, 3D Print, the Lightning Imaging 
Sensor, and several other program and projects at MSFC. The consistency, repeatability, and efficiency resultant from 
this tool is expected to enhance MSFC’s overall success. Through the use of the customization tool, the burden of 
finding the way through the maze of expectations has been lightened by quickly highlighting the appropriate, integrated, 
systems engineering policy path to consider, based on project scale and complexity. As a result, the project teams and 
their governing authorities are better equipped to tailor their implementation approaches in a more cost-effective 
manner. 




ACRONYMS FOR FIG. 2 


CDR-Critical Design Review 
CERR-Critical Events Readiness Review 
COR-Closeout Review 
DCR-Design Certification Review 
DR-Decommissioning Review 
DRR-Disposal Readiness Review 
FR-Formulation Review 
FRR-Flight Readiness Review 
MCR-Mission Concept Review 
MDR-Mission Definition Review 
MRR-Mission Readiness Review 
ORR-Operational Readiness Review 
P - Program 

PDR-Preliminary Design Review 
PFAR-Post-Flight Assessment Review 
PIR-Program Implementation Review 
PFAR-Post-Faunch Assessment Review 
PRR-Production Readiness Review 
SAR- System Acceptance Review 
SDR-System Definition Review 
SIR-System Integration Review 
SR- Status Review 

SRR- Systems Requirements Review 
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